1. Field of the Invention
The present invention relates to telecommunications services and more particularly to a method and system for providing wireless instant messaging.
2. Description of Related Art
Modern technology offers a number of ways for people to interact with each other over a telecommunications network. One of the most popular modes of communication over computer networks, for instance, is electronic mail (e-mail). In an e-mail system, a user at a first client terminal enters a message and sends the message to a destination user. An e-mail server on the network then receives the message and deposits it in an “in box” of the destination user. In turn, the destination user at a second client terminal may then retrieve the message from the in box, read the message and, if desired, prepare and send a response message in a similar manner.
Traditional e-mail communication, however, suffers from an inherent drawback: in order to fully communicate the message from the sending user to the destination user, the destination user must actively retrieve the message from a mailbox. If the destination user is involved with a particular application on the second client terminal, for example, he or she may need to temporarily pause that application, switch to an e-mail application, and open an in box in order to obtain the message.
Ideally, telecommunications should strive to simulate face-to-face interaction. In face-to-face interaction, there is no need to retrieve a message from an in-box; a “sent” message appears in real-time before the recipient. In this respect, therefore, e-mail communications leave something to be desired.
Another mode of network communication that has gained substantial popularity in recent years is “instant messaging.” In a typical instant messaging arrangement, a user at one computer can type a text message to be delivered to a user at another computer, and the message is then delivered in substantially real time to the other computer for immediate presentation to and receipt by the other user. Advantageously, instant messaging thus avoids the need for the recipient to actively retrieve the message from a mailbox and therefore more closely approximates face-to-face communications.
Although instant messaging has been recently popularized by Internet Service Providers (ISPs) such as America Online, Inc., for instance, the concept dates back at least to early UNIX systems. Such systems included a TALK command that allowed a user at one UNIX terminal on a network to send a text message directly to another UNIX terminal on the network. In response to the TALK command, the UNIX operating system would establish a communication channel or “pipe” between a process associated with the first terminal and a process associated with the second terminal. The text message would then be sent along this pipe and would appear immediately on the monitor at the second terminal.
The recent popularity of instant messaging systems is due in large part to the growth of the Internet and Worldwide Web, and the concomitant desire to “be connected.” Two or more users logged onto the Internet may be geographically dispersed but may still want to be able to engage in instant communications with each other, without the need to work through an e-mail server and mailboxes.
Communications over the Internet operate according to an established protocol suite known as TCP/IP (Transmission Control Protocol/Internet Protocol). Each computer terminal or “node” on the Internet is assigned a network address, referred to as an IP address, which defines the location of the terminal in the network. A message to be sent from one terminal to another is divided into a sequence of packets, referred to as TCP or UDP packets, which are then routed through the network to the destination IP address. At the destination, the packets are reassembled, and the message is reconstructed and presented to an end user.
Instant messaging over the Internet can be accomplished in a number of ways. By way of example, FIG. 1 illustrates one possible scenario. In the arrangement shown in FIG. 1, a first computer terminal 12 is coupled by a communications link 14 to a first gateway (GW) 16, and a second computer terminal 18 is coupled by a second communications link 20 to a second GW 22. GWs 16 and 22 each provide connectivity to the Internet, shown as IP network 24. Also connected to IP network 24 is an Instant Messaging (IM) server 26. GWs 16 and 22 and IM server 26 may be owned and operated by a single company, such as a single ISP for instance, or may be owned and operated by separate companies.
In practice, when a first user at terminal 12 logs onto the Internet, an IM client application running on terminal 12 may communicate with an IM server application running on server 26 in order to register the user/terminal as being available for instant messaging service. In doing so, the IM client may establish and provide to the IM server an instant messaging ID for the terminal. This instant messaging ID could comprise a combination of the terminal's IP address and a designated IM port (e.g., a TCP or UDP port) at the terminal, for example. The IM server 26 may then store this instant messaging ID in a database record linked with a name associated with the user, such as “User-1”.
Similarly, when a second user at terminal 18 logs onto the Internet, an IM client application running on terminal 18 may provide an instant messaging ID for terminal 18 to the IM server 26, and IM server 26 may store this ID in a database record linked with a name associated with the second user, such as “User-2”. The IM server may also provide the second user with an indication of other IM clients currently available to receive instant messages. For instance, the IM server may notify the IM client on terminal 18 that User-1 is currently on line and available for IM communication. (Similarly, the IM server may provide the first user with an indication that the second user is available to receive instant messages.)
To send an instant message to User-2, User-1 may invoke the IM client application on terminal 12, type in a text message, and instruct the IM client to send the text message to User-2. The IM client on terminal 12 may then interact with IM server 26 in order to route the text message to a destination IM address comprising the IP address and IM port of terminal 18. For example, the IM server could receive and forward the message to this address, or the IM server could map the user name “User-2” to this destination IM address and the IM client could route the message to the destination. At terminal 18, when the message arrives at the IM port, an IM client application could responsively pop up a window on a monitor and immediately display the message to User-2. In turn, User-2 could send a response IM to User-1 by a similar procedure.
While computers have traditionally been connected to the Internet or other such networks by landline (i.e., wired) connections, recent advances in wireless telecommunications have now opened the door for wireless network connectivity as well. At one level, for instance, a conventional computer can include or be coupled with a cellular radio modem, which can couple the computer with a wireless telecommunications network and in turn, with the Internet. FIG. 2 shows an example of this arrangement.
Referring to FIG. 2, a computer 28 is connected with a cellular modem 30. In accordance with conventional cellular radio telecommunications practice, the cellular modem 30 communicates over an air interface 32 with a cellular base station controller (BSC) 34, which is in turn coupled with a mobile switching center (MSC) 36. MSC 36 is, in large part, the wireless equivalent of a landline telecommunications switch (often referred to as a signal switching point or SSP). MSC 36 is in turn coupled with an “interworking function” (IWF) 38, which commonly serves as a wireless/IP gateway to transparently pass wireless protocol signals (e.g., CDMA, TDMA, etc.) from MSC 36 onto an IP network and vice versa. Thus, IWF 38 is coupled to an IP network 40, to which IM server 26 is also coupled. In an alternative arrangement (applicable throughout this disclosure), a base station controller such as BSC 34 could communicate directly with an interworking function such as IWF 38, i.e., without the need for an intermediate MSC.
The cellular modem 30, BSC 34, MSC 36 and IWF 38 in the arrangement of FIG. 2 may thus take the place of communications link 14 and gateway 16 in the arrangement of FIG. 1. Computer 28, like terminal 12 in FIG. 1, can run an IM client, which can interact with IM server 26 so as to facilitate instant messaging communications with a user at computer 28 as described above.
In addition, other methods for wireless Internet communications have been devised. One of the most significant developments in this regard has been the introduction of the HDML (handset display markup language) and WAP (wireless access protocol) communication standards. Both of these standards are designed to facilitate Internet access from small devices such as cellular telephones, personal data assistants (PDA), and the like. The idea is to implement a scaled down version of a web browser (client) on the device, and to provide a corresponding HDML or WAP server on the Internet that can interact with that browser. The HDML or WAP server can, for instance, send abridged versions of full web pages to the client HDML or WAP browser, suitable for display on a small screen.
FIG. 3 depicts an example of a WAP or HDML client/server arrangement for instant messaging. As shown in FIG. 3, a handheld (or other) device (such as a cellular telephone, PDA, etc.) 42 is arranged to communicate over an air interface 44 with a base station 46. Base station 46 is then coupled with an MSC 48, which is coupled with an IWF 50, which in turn provides connectivity with an IP network 52. (Alternatively the IM server could be coupled with a separate WAP server, or IM server functionality could be integrated within a WAP server. Similarly, the WAP server could be coupled with a separate IM server, or WAP server functionality could be integrated within an IM server.) Also connected to the IP network are a WAP server 54 and IM server 26. A WAP client application on device 42 may thus communicate over IP network 52 with WAP server 54. In turn, WAP server 54 may communicate over the IP network 52 with the IM server 26. Further, a scaled down IM client on device 42 may communicate over the IP network and via WAP server 54 with IM server 26.
Thus, in operation, a user at handheld device 42 could initiate a WAP session with WAP server 54 and, within the WAP session, an IM session with IM server 26. Consequently, the user at device 42 could send and receive instant messages just like a user at terminal 12 in FIG. 1 could do, but with the convenience of a wireless connection.
Still further, another type of messaging system exists for communications in a wireless network. This system is known as short message service (SMS). SMS provides for the communication of short text messages to or from a mobile station (MS) (e.g., a cellular phone, a pager, etc.) or other entity without establishing an active call connection with the entity. In general, the system may allow a person to simply type in a desired text message, indicate the directory number associated with a destination mobile station, and then transmit an SMS message encapsulating the desired text message. The telecommunications network then conveys the text message to the destination mobile station, where the message is typically displayed for receipt by an end-user.
The elements and operation of an exemplary SMS system are defined generally in an industry standard that has been published by the Telecommunications Industry Association (TIA)/Electronics Industry Association (EIA) as Interim Standard IS-41 (“Cellular Radiotelecommunications Intersystem Operations”). The entirety of this standard, including all revisions thereof (e.g., IS-41C, IS-41D, and so forth), is hereby incorporated herein by reference.
To provide SMS service, a wireless network may include a short message service center (“SMSC”) (sometimes also referred to simply as a message center (“MC”)), which is a functional entity that stores and forwards SMS messages. The store and forward function provides a method of sending short messages to their destination recipient or storing those messages if the recipient is unavailable to receive them. This store and forward function can generally be distinguished from the real-time delivery requirements of voice calls, although SMS messages may be delivered in real time.
According to IS-41, the message center can send messages to or from a functional entity known as a short message entity (“SME”). The SME is often an application entity that resides on an MS or other device. When the SME resides on an MS, it may be referred to as an MS-based SME. Alternatively, the SME can comprise, or reside on, another entity in a wireless or fixed network, i.e., in whether or not part of the wireless communications network. For instance, an SME can reside on a landline computer connected to the Internet.
A typical SME might be arranged to compose, store, dispose of, act upon, display and/or otherwise manage short messages. It might also be arranged to perform signaling functions to support other delivery features such as MS location and status queries, and mapping of destination addresses. In turn, a typical SMSC can forward messages to an SME, store short messages for later delivery to an unavailable SME, apply originating and terminating SMS supplementary services to short messages, and serve other functions.
By convention, each MS is registered in a home system. The home system includes a home location register (“HLR”) that defines the services and features authorized for use by the MS. One such service may be SMS. When a mobile station enters a given serving system (typically comprising an MSC and one or more base stations), the serving system engages in signaling communication with the HLR in the MS's home system to notify the HLR where the MS is located and to obtain the MS's current profile. The serving system then stores the profile in a local register (visitor location register (“VLR”) for reference).
Each MS-based SME is usually associated with an SMSC known as the “home SMSC” in the MS's home system. At various instances, such as when the MS first enters an SMS-capable serving system, the MS's HLR will send SME service profile information (e.g., origination and termination restrictions) to serving system along with MS related profile parameters, so that the serving system can know that the MS is qualified to receive and/or send short messages.
Typically, a given SMSC then maintains the mobile identification number (MIN) address information of the MSs that it serves. In the usual case, the MIN of an MS will be the directory number (i.e., telephone number) of the MS, but it could be some other identifier such as an IP address or e-mail address, for instance. In turn, the SMSC is typically addressable by the directory numbers or MINs of those MSs. When the SMSC receives a message for one of its MSs, it may then identify the location of the MS and forward the message via the serving system to the MS.
As further background, FIGS. 4 and 5 illustrate some of the signaling involved in traditional SMS processing, as described, for instance, in Michael D. Gallagher and Randall A. Snyder, “Mobile Telecommunications Networking With IS-41” (McGraw-Hill 1997). FIG. 4 first illustrates a scenario known as two-way-SMS (or mobile-originated SMS), in which one mobile station, MS-A (embodying SME-A), sends an SMS message to another mobile station, MS-B (embodying SME-B).
As shown in FIG. 4, at step 1, MS-based SME-A first sends an air interface message, SMD-REQUEST (SMD-REQ), embodying a short message to its serving system. At step 2, the serving system routes the short message to SME-A's SMSC (message center, “MC”), using an IS-41 SMSDeliveryPointToPoint Invoke (SMDPP) message. Such an SMDPP message may be routed over an industry standard SS7 signaling network to a network point code associated with the SMSC. Alternatively, the SMDPP message could be routed using TCP/IP, X.25 or another desired protocol. The SMSC then returns an “smdpp” acknowledgement message, and SME-A's serving system returns an SMD-ACK to MS-A.
At step 3, SME-A's message center sends an SMDPP message to the Destination SME's SMSC. In turn, at step 4, SME-B's message center sends an SMDPP message to SME-B's serving system. At step 5, SME-B's serving system then forwards the short message to the destination SME using the air interface SMD-REQ message, and SME-B responds with an acknowledgement SMD-ACK to signal acceptance of the SMD-REQ message.
An MS-based SME can be addressed by its host's MIN (e.g., the MIN of the mobile station on which the SME resides). In order to then determine which SMSC to route a message to for a given destination SME, an entity can maintain a table of MIN-to-SMSC addresses (e.g., MIN to SS7 destination point code, or MIN to IP address, for instance), as is often done today in IS-41 networks for routing IS-41 messages to an MS's HLR. Thus, for example, in FIG. 4, MS-A's serving system can maintain a table that indicates the address of the SME-A's SMSC for use in step 2, and SME-A's SMSC can maintain a table indicating the address of SME-B's SMSC for use in step 3.
Generally speaking, in order to terminate an SMS message to an MS-based SME, the SMSC that seeks to send the message must get a valid routing address for the system currently serving the SME. To facilitate this, IS-41 provides a special SMS_Address parameter that is conveyed to the HLR of an SMS-capable MS when the MS is registered in a new serving system. In addition, IS-41 provides an SMSRequest (SMSREQ) invoke message that can be used to request the current location of the MS-based SME.
FIG. 5 illustrates an exemplary set of processing functions that may be employed to register an MS-based SME (residing on MS-A) and to then terminate an SMS message to the SME. As shown in FIG. 5, when an SMS-capable MS is detected by a serving system, at step 1, the serving system sends a RegistrationNotification (REGNOT) invoke message to the MS's HLR. If the serving system is SMS-capable, the message includes the SMS_Address parameter, which can be used to route short messages to the serving system for delivery to the MS-based SME. For instance, if the short message transport network is SS7-based, the SMS_Address parameter may contain an SS7 point code and subsystem number. (Alternatively, as another example, if the transport network is IP-based, the SMS_Address parameter may contain an IP address.) When the serving system receives an SMDPP message addressed to this point code and subsystem number, it assumes the message is intended for a visiting MS-based SME that is specifically identified by address parameters in the SMDPP message.
In turn, when an SMSC seeks to send an SMS message to an MS-based SME, at step 2, it sends an SMSREQ message to the MS's HLR. If the HLR has a valid SMS_Address for the SME, then, at step 3, the HLR returns the SMS_Address parameter in an SMSRequest return result (smsreq) message. At step 4, the SMSC then uses the SMS_Address to route the SMDPP message to the system currently serving the SME, and the serving system in turn sends the message to the SME identified in the SMDPP message, using an SMD-REQ message.
In some instances, an SME may be unavailable to receive SMS messages. This might occur, for instance, (i) if the SME (e.g., an MS-based SME) is not registered with an HLR, (ii) if the SME is registered on an SMS-incapable system, (iii) if the SME is for some reason not authorized for SMS service on the current serving system, or (iv) if the host MS is out of radio contact or intentionally inaccessible (or if its message buffer is full). When an SME is unavailable and the SME's HLR receives a request for the SME's SMS_Address with an SMSRequest message for instance, the HLR may indicate the unavailability to the querying SMSC, by returning an SMS_AccessDeniedReason parameter (e.g., denied, postponed or unavailable).
In an SMSRequest message, in addition to providing the destination MS's MIN (and possibly its electronic serial number (ESN)), an SMSC can provide an SMS_NotificationIndicator parameter, which advises the HLR whether or not to notify the SMSC when the MS becomes available, in case the MS is currently unavailable. When an SMSC sends an SMSRequest message for an MS-based SME to the MS's HLR and the MS is unavailable, the HLR may then store an indication that the SMSC has a message waiting for the MS, unless the SMS_NotificationIndicator parameter indicates that the HLR need not notify the SMSC when the MS becomes available. When the MS then becomes available, the HLR may send an SMSNotification message to the SMSC, providing the SMS_Address of the MS-based SME, and advising the SMSC that it may send the stored message to the SME.
As noted above, SMS service can involve communication over various transport networks, such as conventional SS7 networks, IP networks (e.g., the Internet), and X.25 networks, for instance. In this regard, for example, an MSC, SMSC or other entity may be programmed as, or coupled with, an IWF to convert SMS messages from an SS7-encapsulated form into a form appropriate for IP-transport. This may involve converting an SMS message into a stream of TCP/IP packets for transmission over the IP transport network. This arrangement may allow network access to external IP applications (e.g., SMEs) as well as inexpensive IP access between SMSCs belonging to different networks.
For instance, an SMS message generated in an SS7-based network can be conveyed over an IP network to a POP3 e-mail server, which can then convert the message into an Simple Mail Transfer Protocol (“SMTP”) e-mail message and forward the e-mail message to a designated e-mail recipient (which may therefore be considered a type of SME). As another example, text messages generated and conveyed in an IP network (e.g., by an e-mail client) might be conveyed via the IWF to an SME in an SS7 network. An ISP or other entity may thus allow an Internet e-mail subscriber to send a text message to a designated MS-based SME referenced by a given directory number, for instance. As still another example, an SMSC or MSC in one carrier's network might convey an SMS message, via an IWF and an IP transport network, to an SMSC or MSC in another carrier's network, and the other SMSC or MSC may then deliver the SMS message to a designated recipient.
In summary, the existing art includes two ways to extend instant messaging service into the wireless domain. First, a computer terminal can be equipped for wireless communications with an IM server. As described above, this can involve providing a cellular modem for a conventional computer (e.g., desktop or laptop) and having the computer run a regular IM client application for communication with the IM server. Alternatively, it can involve the use of a handheld device (e.g., cellular phone or PDA) with wireless connectivity, which may employ a WAP/HDML browser to communicate with the IM server. Second, a computer terminal or MS could send a text message, which could be delivered to an MS as an SMS message.